[sacm] Response to Adam's feedback on Vulnerability Assessment Scenario
Jessica Fitzgerald-McKay <jmfmckay@gmail.com> Fri, 06 May 2016 18:25 UTC
Return-Path: <jmfmckay@gmail.com>
X-Original-To: sacm@ietfa.amsl.com
Delivered-To: sacm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3CBE12D0E4 for <sacm@ietfa.amsl.com>; Fri, 6 May 2016 11:25:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.688
X-Spam-Level:
X-Spam-Status: No, score=-2.688 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_FREEMAIL_DOC_PDF=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pRAQsWEa7PHb for <sacm@ietfa.amsl.com>; Fri, 6 May 2016 11:25:34 -0700 (PDT)
Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9ABA612D0B9 for <sacm@ietf.org>; Fri, 6 May 2016 11:25:33 -0700 (PDT)
Received: by mail-oi0-x22f.google.com with SMTP id x201so148465233oif.3 for <sacm@ietf.org>; Fri, 06 May 2016 11:25:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to; bh=3lLqonyPpDYROpnO2ZNgZzfrkG9OTcqJ7oMsFxfretc=; b=mcNAl740M9NmVmw52JCwig71pMDPj4ga9/oouR5eLSuZQeQrnNEamdxl93ZODTutEa PdmSXXxH4LUVsFW45mdr70tidFu1VzL1R2jp0hIuX2kdHGRRg1mGQvD9ey6AiXkvMeYG GQysqilTTQ48j46v/GdT5kL8SCZYQ0ooKNDx2jHtwFmwi4N2MVddExYLWZ4lKx78rZEl fHroPP1iSRvbYpRhW1fgb8ik0hGUKcFtlEyQ3GQzFk41luXQx+g6jnAcBN18sPWUL3Q7 24ym9n+L0Rv1qwMH25qizzLdvYg4HEEewVCXJrCi/w/SEwKM3KaS97v+BrxBJwVHvuvv JYwA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=3lLqonyPpDYROpnO2ZNgZzfrkG9OTcqJ7oMsFxfretc=; b=crQOQFmloYm7Xu1PAkDyg20gjQtj/cUbRW7GL+S5CZiUQyBxkyz1ObG8Xx46qY5oFK aZqXVQsD1fAxDyVUAMV3vy8kqqIPuAsZZvSV7FdSPEJHjzlP/VTVJtc2EXyKjmUhWtCk QbwC1MEarAIok8tsmnUje1R6jbbcl74Wk+sWkt60IYuMnzM+3ToxA76rWK6MKrZjcCN8 eyEZDosCCp1TLY1R+yE/h+ZWqiMIi93X/d4PNkTq43Lr+8vVb8XGyD2ayc7Tz99VI2CK HLBJHPWoI91oUK3GBsfcOgB3gmSZWnlLjQg+R43IdyG1VA7x3OissK/dWFz9CLzIOfW1 8TKw==
X-Gm-Message-State: AOPr4FXPhfnQiLRE7qEHbLBitWeMaIK6RnXFwdqv2lhwgf0DwpC+GD99p8lD1DuXOx9Tpiu/L7e0WQJxavOvVA==
MIME-Version: 1.0
X-Received: by 10.202.90.3 with SMTP id o3mr9401029oib.96.1462559132693; Fri, 06 May 2016 11:25:32 -0700 (PDT)
Received: by 10.182.120.166 with HTTP; Fri, 6 May 2016 11:25:32 -0700 (PDT)
Date: Fri, 06 May 2016 14:25:32 -0400
Message-ID: <CAM+R6NW_KwUSDAErbcoQ1bw10k37r+b3N0fj9OnnxO-uf6cOgA@mail.gmail.com>
From: Jessica Fitzgerald-McKay <jmfmckay@gmail.com>
To: "sacm@ietf.org" <sacm@ietf.org>
Content-Type: multipart/mixed; boundary="001a113d5edc91a4cc0532309542"
Archived-At: <http://mailarchive.ietf.org/arch/msg/sacm/H4OIKC6ZmqyHE17qaIk_FYgfsdI>
Subject: [sacm] Response to Adam's feedback on Vulnerability Assessment Scenario
X-BeenThere: sacm@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: SACM WG mail list <sacm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sacm>, <mailto:sacm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sacm/>
List-Post: <mailto:sacm@ietf.org>
List-Help: <mailto:sacm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sacm>, <mailto:sacm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 May 2016 18:25:37 -0000
Adam, thank you for taking the time to make such extensive edits. The document flows a lot better now, and is much easier to read. Danny, Charles and I collaborated on our review, and made some additional edits to your work. They are attached to this email.There are some edits we would like to call out for particular attention by the group: - We got ourselves confused by the definition for Vulnerability Management Capability. We added some clarifying (to us) text, so the definition now reads: "an enterprise IT capability managing endpoint vulnerabilities and associated metadata on an ongoing bases *by ingesting vulnerability description information and vulnerability detection data, and performing a vulnerability assessment*". - Throughout the document, we made changes to clarify when we were talking about vulnerability detection information and vulnerability detection data. - We added a definition for Target Collection (referenced in Section 5 and previously undefined). It reads: "The task of collecting specific endpoint information from the target endpoint in order to make a determination about that endpoint (vulnerability status, identification, etc.)". We're not sure we are happy with it, though. See open issue #3. - We added some clarifying words to the beginning of Section 4. - In section 4.2, we changed "vulnerability assessment flow" to "vulnerability assessment". They seemed equivalent the way they were being used in this document, and "vulnerability assessment flow" didn't appear anywhere else in the document. - We clarified the text in Section 5 regarding vulnerability detection. Previously, it read: Vulnerability detection may be done in a number of ways, depending upon the specific vulnerability", followed by a bulleted list of endpoint information that may be used to detect a vulnerability. It now reads: Vulnerability detection relies on the examination of different endpoint information depending on the nature of a specific vulnerability. Common endpoint information used to detect a vulnerability includes:", followed by the same bulleted list. - We reworded the fourth paragraph in Section 5 (beginning, "The breadth of information required. . ." for clarity. - In Section 5, paragraph 5, we substituted "vulnerability assessment capability" for "vulnerability assessment mechanism". There are still questions remaining after our review. We would like to get the work groups feedback on the edits list above, as well as on the following open issues: 1) We need to determine which items in Section 2 ("Terminology") should be pulled from the Vulnerability Assessment Scenario and included in the SACM-wide Terminology draft. Those terms which are only used in the Vulnerability Assessment Scenario should be defined in this document; however, any of these terms that will be reused in other SACM documents should be defined in the Terminology draft. 2) In Section 2 ("Terminology"), vulnerability detection data is defined as "a representation of vulnerability description information describing specific mechanisms of vulnerability detection". We interpret this to mean that vulnerability detection data is a representation of vulnerability description information that can be used by network tools that participate in the vulnerability assessment process. Does the group agree that is the case? If so, is vulnerability detection data a type of guidance, as described in the SACM Information Model? 3) Regarding the definition of Targeted Collection: a) Does targeted collection refer to a server explicitly requesting additional information from the endpoint to supplement automated collection? Should the definition be more precise? b) Is "targeted collection" even the right term to use in Section 5? It makes other forms of collection sound un-targeted. Would "supplemental collection" be a better term? 4) In Section 3, the first bullet states that vulnerability description [information] is processed "into a format that the enterprise's security software tools can understand and use". Is that the equivalent of saying that the vulnerability description information can be processed into vulnerability detection data? And is this also equivalent to what we are trying to say in the third bullet, when we say "The enterprise has a means of extracting relevant information about enterprise endpoints in a form that is compatible with the vulnerability description information"? 5) Section 5, paragraph 5 states: "the information beyond that which is available in the endpoint management capability can be pushed to the vulnerability assessment capability by the endpoint whenever that information changes". However, we feel this must necessarily be an information pull, not a push, since the endpoint cannot know what information is needed until the server requests it. Does the group agree? 6) Appendix B, paragraph 2 states: "Moreover, the scenario incorporates long-term storage of collected data, vulnerability description information, and assessment results in order to facilitate meaningful and ongoing reassessment." At the SACM side-meeting, there was tentative agreement that SACM was concerned with data-in-motion, not data-at-rest. Is clarifying language needed here to address that concern? 7) Appendix D.2 seems more appropriate for the information model, rather than this document. Does the group agree? We're looking forward to hearing everyone's feedback. Jess On Fri, Apr 8, 2016 at 12:06 PM, adammontville <notifications@github.com> wrote: > I should also disclose that while I referenced the data table, I did not > take the time to update the column headers of that table or to add to it, > if necessary. Personally, I like the idea of referencing the data table, > but I understand that others may view the world differently. > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly or view it on GitHub > <https://github.com/sacmwg/vulnerability-scenario/issues/4#issuecomment-207495214> > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm > >
- [sacm] Response to Adam's feedback on Vulnerabili… Jessica Fitzgerald-McKay
- Re: [sacm] Response to Adam's feedback on Vulnera… Haynes, Dan